Mission 3/Mission 3.zip/Mission 3.iso/spiele/sac/manual/chapter4.doc

Text File | 2012-11-26 | 24KB | 544 lines

                          CHAPTER FOUR
                      (The editor program)
 *****************************************************************

   What you have now is a simple adventure game. Loading the games
   data into the tester program (TEST.PRG) just allows you to see
   if everything is correct. In other words you should now be able
   to take, examine, drop, wear, and move objects. You should also
   be able to move from location to location using the movement
   commands (north, south, etc...), and other commands like
   "look" and "quit" work as normal.

   Typing "i" for inventory would have given you a list of any
   objects carried and worn as inputed in the creator program, if
   you see any mistakes such as spelling mistakes then all you
   have to do is load the data file back into the creator, check the
   data you put in and use the amend options to correct them. After
   this, save the data file back to disk with the name "TEST.ADV".

   If everything is fine then we can continue with the final stage
   of creating an adventure but first look at what you've done so
   far, you have created an adventure game quickly and easily
   without the need of any programing skills so why not sit back,
   relax and have a brew and maybe a fag and admire your work.

   The next stage of creating an adventure with sac involves a bit
   of programming using STOS basic to add the extra information to
   the game. Don't worry if your programing skill is'nt so good as
   I will be providing the needed routines for you.

   Load up STOS and type "load "editor.bas" or just use the file
   selector to load it. When it has loaded, list it and have a
   look at it. This is the editor program which already contains
   the routines found in a standard adventure game and we are
   going to add some extra lines to it.

   As you can see, sac is not a normal adventure creator like
   STAC, its a programing tool for STOS. Seeing the editor program
   is a normal STOS basic listing you can add extra touches like
   music and samples and anything else you can think of.

   I will now take you step by step through the editor program.

 *****************************************************************
                           VARIBLES
 *****************************************************************

   Varibles are things that check on the status of things, for
   example they can be used to see if a door is open or closed.

   Varibles is set up like this......

    10 let A=1 : let A$="hello"

   Here we see the use of the LET command which is the command
   used for setting varibles. You can think of varibles as small
   boxes with a label on, containing numbers or words.

   Look at lines 110 to 230 of the editor program and you will see
   that this is the part of the program where we put our varibles.
   Looking at line 110 we see some varibles already set, these are
   needed by the editor program and must not be changed or used
   for other purposes. Lets see what they mean.

   LOC:- This varible holds the present location number, this is
   set to 1 which tells the game to start from location one.

   TURNS:- Every time you do something in an adventure it adds one
   to this varible. For example typing a command like "get lamp"
   would add one turn and "go north" would add another turn.

   SC0RE:- This varible holds the players present score.

   CARRY:- Holds the number of objects carried, this varible
   equals another varible called CAR, this varible is used in the
   creator program and its tells the editor program how many
   objects you entered as CARRIED. In St brides there is only one
   object put in the carried location so CAR would equal 1.

   WEAR:- This holds the number of objects presently in the WORN
   location, like CAR it is set to the varible WEA setting the
   WEAR varible to the number of objects in the WORN location.

   The next line has three varibles holding the special location
   numbers that the creator uses. More details on this later.

   You will have noticed that none of these varibles use the LET
   command. Well you can use it if you want but STOS allows you to
   omit it. So you can type "A=1" instead of "let A=1".

   You can give your varibles any name you like except for those
   used by the editor program. Heres a list of them.


  LOC,TURNS,SC0RE,CARRY,CAR,WEA,X,Y,A,B,FOUND,NO,D,DONE,COUNT,CHAR
                 TEST,OB,LO,SCR,OBJ,EO,ME,EL.

                  Other names are okay to use.

   STOS has a small problem with varibles, if it finds one with a
   keyword in it then it will cause an error. For example if you
   decided to name your varible as SINGLE, this would be
   pronounced by STOS like this.....

   150 sin GLE=2

   As you can see STOS thinks you are using the SIN command.

   If you look at the SC0RE varible you will see that the letter O
   is a nought, this stops STOS interperting line 110 as....

   110 LOC=1 : TURNS=0 : SC or CE=0 : CARRY=CAR : WEAR=WEA

   Line 40 of the editor program holds the DIM commands needed by
   the editor and there are three other arrays called EXIT$, EXIT
   and WRD$. DIM commands other than these can be used.

   We shall discuss the use of varibles in the next section but
   first look at lines 80 and 100 of the editor program.

   Line 80 loads a title screen, so before you can run the editor
   program you will have to put a screen called SAC.PI1 on the
   same disk you are currently using unless you delete it.

   Line 100 uses the FADE command to make the first two colours in
   the present palette black for the background and white for the
   text. This can be changed to the first two colours of your choice.

                     HIGH PRIORITY EVENTS
  ****************************************************************

   An high priority event is the part of the game that checks the
   present location before the player, these can be used to inform
   the player of his condition.

   Looking at the editor program we see that lines 330 to 550 are
   reserved for your own H-P events, lets say that the player has
   hurt his leg, an H-P event could tell him about it.

   First we could define a varible called LEG, this could be set
   to 0 at the start of the game. So if the player hurt his leg by
   falling in a pit you could set LEG to 1, then you can test if
   his leg is hurt with the following line.......

   340 if LEG=1 then print MESSAGE$(1)

   The MESSAGE$(1) part of the line holds a message telling the
   player that his leg hurts, this is an array which holds the
   messages you defined in the creators MESSAGES option.

   An array is a row of boxes with the same label and each box can
   contain letters or numbers. For example the command DIM A(10)
   labels ten boxes with the letter A.

   In the above example the game would print message 1 if the
   varible LEG was set to 1. Message 1 could be......

                  Your leg hurts a lot.

   In St brides an H-P event is used to see if the player is
   wearing the teachers gown. If he is then the game will display
   message 3 otherwise it will display message 4. Play the game
   and go into the staffroom wearing the teachers gown, read the
   message, leave, remove the gown and go back in and read the new
   message. You will then understand what I mean.

   So there we have it. An H-P event is the part of the adventure
   that checks the location just before the player enters it.

         More about high priority events later on.

                     DIFFERENT EXITS
  ****************************************************************

   Normally when the player tries to go in a direction thats
   blocked off the game will just tell him that he can't go that
   way. This would be useless if the player tried to go up an hill
   and the game told him that he could'nt go that way. He would
   want to know why. Look at this location description...

   You are in a clearing surrounded by dense forest. To the east
   is a footpath and north leads into a cave.

   Lets say we wanted to block the cave with a large rock, we
   could define a message saying "A large rock is in the way."
   then avoid entering the connection north to the inside of the
   cave from the above location.

   The editor program uses an array called WRD$(WN) which contains
   the words entered by the player. WN is the number of the word
   and ranges from 1 to 10 so if the player entered "hit troll"
   then WRD$(1) would be "hit" and WRD$(2) would be "troll".

   This would be used in a line like this.....

   10 if WRD$(1)="hit" and WRD$(2)="troll" then (do something)

   There is also a varible called D which holds the number of the
   direction command entered, Heres a list of them.

      North (direction 1)     North west (direction 5)
      South (direction 2)     North east (direction 6)
      West  (direction 3)     South west (direction 7)
      East  (direction 4)     South east (direction 8)
           Up (direction 9)   Down (direction 10)

   We can now enter this line in the different exits section.

   810 if WRD$(1)="go" and WRD$(2)="north" and LOC=10 and D=0 then
       print MESSAGE$(5)

   Here we see the use of the LOC varible which tells the adventure
   only to carry out this line if the above location is location
   ten and the player types "go north". If there is no connection
   north then D is set to nought otherwise it is set to 1. The
   line then prints message 5 telling the player about the rock.

   Note the above line is only carried out if "go north" is typed,
   if "n" which is short for "go north" then you would have to
   enter the extra line to check for this like so.

   820 if WRD$(1)="n" and LOC=10 and D=0 then print MESSAGE$(5)

                     SPECIAL GET COMMANDS
  ***************************************************************

   Normally the player can get any objects lying around in the
   present location but the player could try getting a snake which
   would'nt be too happy about being kidnapped. Normally an object
   would be moved to the carried location after being picked up but
   a snake could bite the player and poison him.

   Lines 1160 to 1320 are reserved for these special get commands,
   such a line would appear as...

   1170 if WRD$(2)="snake" and OB_LOC(2)=LOC then print MESSAGE$(4)
        : goto 2610

   Whenever the player wants to get an object this part of the
   adventure is reached, the word "get" goes into WRD$(1) and then
   the editor program looks for the object word in its list. When
   its found it checks if the object is at the present location
   and if so, moves it to the carried location.

   Here we see yet another array called OB_LOC(OP) this holds the
   present location of object OP. The above line is checking if
   object 2 (the snake) is in the same location as the player.

   If the line is carried out then message 4 is printed...

        The snake has bitten me. I'm dead.

   As the player has been killed, the command GOTO 2610 is used.
   Line 2610 is the part of the program that tells the player his
   score and number of turns taken then ends the game.

   The special get commands could be used in other ways like if
   the player picks up a magic sword which restores strength.

                  SPECIAL DROP COMMANDS
  **************************************************************

   Like GET, you can use these commands to allow something special
   to happen if the player drops a certain object. For example if
   your adventure required the player to drop a casket down an hill
   you could then move the object to the location at the bottom of
   the hill with the following line.

   1480 if WRD$(2)="casket" and OB_LOC(8)=CARRIED and LOC=10 then
        OB_LOC(8)=6 : print MESSAGE$(7) : NO=1 : DONE=1 :
        WRD$(1)="" : WRD$(2)=""

   This is quite a long line so lets go through it step by step.

   This line checks if the object word is "casket" which is object
   number 8 and if its in the carried location and the player is
   at location ten (the hill). If so then it moves the casket to
   location six (bottom of the hill) then prints MESSAGE$(7) to
   tell the player the casket has been dropped down the hill.

   The new version of the editor program has been updated to allow
   you to group commands together like this....

   Get the lamp and light it then drop sword

   This prints up the three messages....

    You now have the lamp.
    The lamp is now lit.
    You have dropped the sword.

   This works by going through all the commands to a routine that
   checks for the words "and" and "then". If found it loops back
   to the start of the command lines and carrys out the commands
   after any of these two words. For this to happen you need to
   put the following at the end of each line.....

    NO=1 : DONE=1 : WRD$(1)="" : WRD$(2)=""

   If its a line that ends the game, then you don't need to bother.

   Lines 1470 to 1610 are reserved for these commands.

                      REVEALING OBJECTS
  ****************************************************************

   As mentioned before, objects can reveal other objects. For this
   example we shall use two objects. A vase and a key. In this
   example we shall allow the key to be found in the vase when the
   vase is examined. So using the creator we define the vase and
   put it in a normal location, then define the key and put it in
   the not created location using the special locations option.

   Next we define a message that says "Theres a key in it.". So
   what we need to do is bring the key from the not created
   location to the present location when the player examines the
   vase. Lines 1730 to 1810 is the part of the program which is
   reserved for these commands.

   The line to carry out the above example would be....

    1740 if WRD$(2)="vase" and OB_LOC(1)=CARRIED and OB_LOC(2)=NC
         then print MESSAGE$(1) : OB_LOC(2)=LOC

   So if the player types "examine vase" which is object one and
   its carried by the player and object 2 (the key) has'nt been
   created yet then message 1 is displayed telling the player he's
   found the key and moves the key to the present location.

   Don't forget to add the NO=1 : DONE=1 : WRD$(1)="" : WRD$(2)=""
   on the end of these lines so it can group with other commands.

   Another use of these commands can be for a crystal ball
   destroying the player if he examines it.

   1750 if WRD$(2)="ball" and OB_LOC(2)=CARRIED then print
        MESSAGE$(5) : goto 2610

   This line tells the player he's dead and ends the game.

                   REVEALING LOCATIONS
  **************************************************************

   As with the objects we can do other things when the player
   examines part of the present location. Normally the player would
   be given a description like "A fire burns proudly in it." if he
   examines a fireplace in a living room.

   In the revealing objects section a key was found in a vase, so
   for this example we shall create the key and put it in a door.

   1900 if WRD$(2)="door" and OB_LOC(2)=NC and LOC=5 then print
        MESSAGE$(6) : OB_LOC(2)=LOC

   This line is a bit like the one in REVEALING OBJECTS but only
   carrys out the line if the player is at location 5.

   As before you can use this part of the program for other reasons.

         Lines 1890 to 1970 are reserved for these lines.

                     SPECIAL WEAR COMMANDS
  ****************************************************************

   Normally any object can be worn and the adventure just tells
   the player that he's wearing it. But a suit which is too small
   would rip and an hat which is too big could stop the player
   from seeing. For this to come into practise we would use a
   special wear command.

   2060 if WRD$(2)="hat" and OB_LOC(7)=CARRIED then print
        MESSAGE$(3) : NO=1 : DONE=1 : WRD$(1)="" : WRD$(2)=""

   So if the player types "wear hat" then message 3 is printed
   which would say "The hat won't fit so you take it off". The
   reason for the WRD$(1) and WRD$(2) being cleared is to stop the
   normal wear commands being carried out.

      Lines 2050 to 2120 are reserved for these commands.

                      SPECIAL REMOVE
  ***************************************************************

   Like special wear commands, we can do special things if the
   player removes an article of clothing. For example removing a
   warm jacket in an house would'nt mean anything but removing it
   in a very cold place could make the player freeze to death.

   2230 if WRD$(2)="coat" and LOC=20 and OB_LOC(10)=W0RN then
        print MESSAGE$(14) : goto 2610

   So if the player types "remove coat" and he's in location 20
   which could be a snowy field then message 14 tells him he has
   frozen to death and the game ends.

       Lines 2220 to 2290 are reserved for these commands.

                    OPEN AND CLOSE COMMANDS
 ****************************************************************

   You will have noticed that in St brides you can walk from room
   to room without opening any doors. Well if are walking around
   the countryside we don't have to open or close any doors but an
   house would normally have most of its doors closed. So we use
   lines 2390 to 2440 to see if the player wants to open one.

   The creator uses an array called MAP to store the connections
   from each location. The format of this array is MAP(L,D).

   As the player can't go to another location because a closed
   door is in his way, we use the MAP array to connect his present
   location to the next one. L is the location number and D is the
   direction number which ranges from 1 to 10.

   This line would open a door at location 15

   2400 if WRD$(2)="door" and OP=0 and LOC=15 then MAP(15,1)=16 :
        OP=1 : print MESSAGE$(11) : NO=1 : DONE=1

   And this line would close a door at location 15.

   2490 if WRD$(2)="door" and OP=1 and LOC=15 then MAP(15,1)=0 :
        OP=0 : print MESSAGE$(12) : NO=1 : DONE=1

   Line 2400 connects direction one (north) from location 15 to
   location 16 using the MAP array. OP is a varible which would be
   set to nought if the door is closed and one if its open.

   Look at the following location.....

   You are in a bedroom. A door leads north.

   At the moment the player can't go through the door cause its
   closed so when he opens it we use MAP to connect the bedroom
   to the location beyond the door. Lets say the bedroom is
   location one and location 2 is an hallway which is north.

   To connect the two locations together we could use MAP like this.

                           MAP(1,1)=2

   So the first number is one meaning location one, the second
   number is the direction number (in this case north) and the
   third number is location two. So this means define a connection
   north from location one to location two.

   If we wanted to un-connect the two locations then MAP would
   equal nought. This can be used to close doors. Here are some
   other examples to make this a bit clearer.

   MAP (4,2)=6:- (defines a connection south from location 4 to 6)
   MAP (7,4)=4:- (defines a connection east to location 7 to 4)
   MAP (2,9)=0:- (un-connects connection up from location 2)
   MAP (8,3)=0:- (un-connects connection west from location 8)

   Lines 2480 to 2530 are reserved for the close commands.

                        LOW PRIORITY EVENTS
 *****************************************************************

   Low priority events are any other commands that the player may
   type in, these are commands such as "light lamp", "kill beast"
   or even "make tea". All the other commands discussed in this
   chapter like "get", "drop", "examine", "wear","open" etc... are
   commands found in every adventure game but L-P events are used
   for other events happening in your adventures.

   Suppose your adventure required the player to kill a dragon,
   you would define a varible called DRAGON this would set it to one
   if the dragon is alive and two if it was dead. You would then
   define two messages. The first one saying "A dragon is here."
   and the second one saying "A dead dragon is here".

   You could put this dragon in a location using H-P events.

   850 if LOC=10 and DRAGON=1 then print MESSAGE$(1)
   860 if LOC=10 and DRAGON=0 then print MESSAGE$(2)

   So when the player enters location ten he will be imformed of
   the dragon. If its alive message one will print up and if its
   dead message two prints up.

   To check for the player killing the dragon just enter this line
   as a low priority event.......

   2780 if WRD$(1)="kill" and WRD$(2)="dragon" and DRAGON=1 and
    LOC=10 then print MESSAGE$(3) : DONE=1 : WRD$(1)="" : WRD$(2)=""

   I'll now show you how to light a lamp using L-P events.

   Using the creator, define two objects.....

   1. a lamp.
   2. a lit lamp

   Put the lamp in the carried location and the lit lamp in the
   not created location. The lit lamp does not yet exist in the
   game because all not created objects go to location nought, in
   other words they are put aside until the game puts them in
   another location. What we are doing here is swapping the two
   lamps when the player types "light lamp".

   This is done by the following line.......

   2790 if WRD$(1)="light" and WRD$(2)="lamp" and OB_LOC(1)=CARRIED
        then OB_LOC(1)=NC : OB_LOC(2)=CARRIED : print MESSAGE$(3)
        : DONE=1 : WRD$(1)="" : WRD$(2)=""

   This line checks if the lamp is carried and if so puts it to
   the not created location then it moves the lit lamp from the
   not created location to the carried one and prints message 3 to
   tell the player the lamp is now lit.

   There are loads of L-P commands you could think of, which ones
   you use depend on what happens in your adventure. Chapter five
   gives you more information on all the different things you can
   do to make a great adventure game.

   Lines 2760 to 3210 are reserved for your L-P commands.

   Well we are near the end of this chapter (sob!!!) and maybe
   there are one or two things you don't understand well don't
   worry, because chapter 6 takes you step by step into creating a
   game and all the data and commands are written out for you.
   Plus if you did register with me you would have recieved two
   extra games and chapters 5 and 6 along with the STOS source
   code to the example adventure games. You will also have the
   option to get in touch with me by post or phone for help.

   If you do register then I promise that it would be worthwhile
   as a shareware author promises to be friendly with his or her
   subscribers and sometimes offers extras. For example I offer
   you free copys of games I write with sac and when I get a
   printer you will get a sac manual for a cut price.

   Just a couple more things to mention. Line 3380 of the editor
   program loads the data that you created with the creator, this
   at the moment looks for a file called GAME.ADV but you can
   change it to the name of your data file. Line 3610 also needs
   to be changed to your data files name.

   Well thats it for this chapter, see you in chapter 5.